Archivi categoria: Windows 10

PowerShell Core 6.0: una nuova era ha inizio

Facebooktwittergoogle_plusredditlinkedin

Da qualche giorno è disponibile una nuova versione di Windows PowerShell, giunta ormai alla sesta versione. La grande novità risiede nell’introduzione della versione Core, che ha l’obiettivo di portare l’utilizzo della shell Microsoft su tutti […]

Gestire l’accesso alle macchine virtuali in Microsoft Azure con la funzionalità JIT (Just-in-Time)

Facebooktwittergoogle_plusredditlinkedin

Mai come in questo periodo il tema della sicurezza informatica sta monopolizzando gli articoli e gli avvisi che ci arrivano dai diversi vendor hardware e software e gli attacchi si stanno non solo evolvendo come complessità, ma soprattutto stanno aumentando. Difendersi dagli attacchi è sempre impegnativo e non bisogna mai sottovalutare nulla, ma io sono dell’idea che prevenire sia meglio che curare e quindi nell’approccio alla sicurezza la cosa più importante è ridurre la superficie di attacco.

Avevo già parlato in un precedente articolo di una funzionalità di sicurezza introdotta in Windows Server 2016 e chiamata Just Enough Administration (JEA), che ha come scopo quello di aumentare la sicurezza nella gestione e nella delega dei privilegi in Windows Server. In questo articolo invece vi parlo di una funzionalità di Microsoft Azure, attualmente in PREVIEW e che si chiama Just in time VM Access, che può essere usata per bloccare il traffico in ingresso verso le porte dei protocolli di amministrazione (RDP per Windows oppure SSH per Linux) delle macchine virtuali di Azure, riducendo l’esposizione agli attacchi.

Figura 1: Attivazione della funzionalità di Just in time VM Access in Azure Security Center

Questo tipo di funzionalità non è pero disponibile gratuitamente e fa parte del piano Standard del Centro Sicurezza di Azure (Security Center), che offre la gestione unificata della sicurezza e la protezione avanzata dalle minacce per tutti i workload in esecuzione in Azure, in locale nella propria rete aziendale e in altri cloud. È possibile aggiornare tutta la sottoscrizione di Azure al piano Standard, che viene ereditato da tutte le risorse all’interno della sottoscrizione oppure è possibile aggiornare a un solo gruppo specifico di risorse (Resource Group). Per poterlo fare è sufficiente modificare la Security Policy del Security Center come mostrato in figura:

Figura 2: Modifica delle Security Policy e del Pricing Tier in Azure Security Center

Nel momento in cui attivate la funzionalità di Just in time VM Access, Il Security Center protegge il traffico in ingresso verso le macchine virtuali creando una regola nel Network Security Group (NSG) utilizzato dalle schede di rete della VM, che blocca le porte di gestione. Quando avrete necessità di accedere in modalità amministrativa alla VM, vi basterà richiedere l’accesso e indicare per quanto tempo necessitate di amministrare la macchina. Il Security Center provvederà a modificare le regole sul Netowrk Security Group consentendo il traffico in entrata verso le porte di gestione per il periodo di tempo specificato. Al termine di questo periodo, il Security Center ripristinerà le regole preesistenti.

Attivazione del Just in time VM Access

La prima volta che vorrete usare la funzionalità di Just in time VM Access vi verrà chiesto di attivare (in prova gratuita per i primi 60 giorni) il piano Standard, come mostrato in figura:

Figura 3: Attivazione del Piano Standard per Azure Security Center

Una volta che avrete attivato il piano Standard potrete tornare nella console del Just in time VM access e visualizzare le informazioni per ogni macchina virtuale, divise in 3 categorie:

  • Configured – Macchine virtuali che sono state configurate per supportare l’accesso Just-In-Time. I dati visualizzati sono relativi all’ultima settimana e includono, per ogni macchina virtuale, il numero di richieste approvate, la data dell’ultimo accesso e l’ultimo utente che ha effettuato l’accesso.
  • Recommended – Macchine virtuali che possono supportare l’accesso Just-In-Time, ma che non sono state ancora configurate.
  • No Recommandation – I motivi per cui una macchina virtuale può risultare non raccomandata sono:
    • Network Security Group mancante – La soluzione Just-In-Time richiede la presenza di un gruppo di sicurezza di rete.
    • Macchina virtuale classica – L’accesso Just-in-Time alle macchine virtuali attualmente supporta solo VM distribuite tramite Azure Resource Manager.
    • Endpoint Protection non installato – Il Centro sicurezza di Azure monitora lo stato della protezione antimalware e verifica che nella VM sia installato Endpoint Protection

Figura 4: Macchine virtuali su cui non può essere abilitata il Just in time VM access

Per abilitare la funzionalità è sufficiente selezionare la VM, cliccare sul pulsante Enable JIT on VM e nel blade che si apre cliccare su Save, come mostrato in figura:

Figura 5: Abilitazione della funzionalità di Just in time VM access

Richiedere l’accesso a una macchina virtuale

Per richiedere l’accesso ad una macchina virtuale è sufficiente selezionare la VM nella scheda Configured e cliccare sul pulsante Request Access. Nel blade che verrà aperto definite quale porta aprire, a quali indirizzi IP permettere la connessione, per quanto tempo permettere la connessione. Al termine della scelta dei criteri cliccate sul pulsante Open Ports, come mostrato in figura:

Figura 6: richiesta di apertura delle porte di amministrazione

In qualsiasi momento potete modificare la configurazione dell’accesso JIT alla VM, visualizzarne le proprietà e i log delle attività, come mostrato in figura:

Figura 7: Modifica della configurazione dell’accesso JIT alla VM

È sempre possibile aggiungere altre porte alla configurazione dell’accesso JIT alla VM e per ognuna di loro stabilirne anche la durata, che in ogni caso non potrà superare le 24 ore.

Figura 8: Aggiunta di una nuova regola alla configurazione dell’accesso JIT alla VM

Visualizzando la scheda Networking della macchina virtuale potrete visualizzare quali regole sono state applicate al Network Security Group della VM. Sono state inserire le regole di SecurityCenter-JIT che hanno una priorità più bassa e quindi hanno precedenza rispetto alle altre regole create.

Figura 9: Regole di SecurityCenter-JIT applicate al Network Security Group della VM

Conclusioni

La semplicità con cui è possibile configurare l’accesso Just in Time alle VM di Azure permette di poter ridurre drasticamente la superfice d’attacco verso le VM esposte, come ad esempio le Jump Box con IP pubblico, ed impedisce di fatto tutti gli attacchi verso il Desktop Remoto o verso Secure Shell che cercano di indovinare le credenziali amministrative. Un modo semplice ed efficace per proteggerci e per mitigare gli attacchi di forza bruta aprendo le porte solo durante la connessione per eseguire attività di gestione o manutenzione sulle VM.

CPU vulnerability & speculative execution side-channel attacks: impatto sui sistemi operativi Microsoft e sull’infrastruttura Azure

Facebooktwittergoogle_plusredditlinkedin

[Trovate in fondo al post alcuni aggiornamenti] Rientro più rapido del previsto e del pianificato alle mie attività su questo blog, dovuto alle vulnerabilità delle CPU documentate ufficialmente nelle ultime ore e ai potenziali attacchi “speculative execution side-channel attacks” CVE-2017-5715 (branch target injection) CVE-2017-5753 (bounds check bypass) CVE-2017-5754 (rogue data cache load) Potete trovare maggiori…

Limitare i privilegi amministrativi utilizzando la Just Enough Administration (JEA)

Facebooktwittergoogle_plusredditlinkedin

La Just Enough Administration (JEA) è una delle novità di sicurezza del Windows Management Framework 5.0 che permette di limitare le sessioni amministrative solo ad un particolare set di comandi e aumenta di fatto la sicurezza nella gestione dei nostri sistemi.

Questo tipo di funzionalità, basata sull’amministrazione PowerShell remota (Windows PowerShell Remoting), permette di configurare degli endpoint in modo tale che quando un utente si connette per eseguire delle cmdlet di PowerShell remote, gli venga concesso l’utilizzo di solo alcuni script e di alcuni comandi. Ad esempio, potreste limitare per un utente la possibilità di amministrare il DNS e di eseguire solo alcune delle cmdlet relative alla sua gestione. Se il ruolo DNS è installato sul controller di dominio Active Directory (come di regola avviene), gli amministratori DNS richiedono privilegi di amministratore locale per risolvere problemi con il server DNS, e per fare ciò è necessario che siano membri del gruppo di sicurezza con privilegi elevati “Domain Admins”.

JEA permette di evitare l’uso di account privilegiati. L’utente si connette all’endpoint remoto JEA utilizzando uno speciale virtual account privilegiato invece che il proprio account utente. I vantaggi di questo tipo di approccio sono molteplici:

  • Le credenziali dell’utente non verranno memorizzate nel sistema remoto e nel caso questo venga compromesso non sarà possibile rubare le credenziali
  • L’utente che utilizzate per l’amministrazione remota non dovrà essere privilegiato e potrà essere un normale utente di dominio
  • Il virtual account è valido solo nell’host dove si trova e non può essere riutilizzato per connettersi ad altri sistemi remoti
  • Il virtual account ha privilegi amministrativi sull’host, ma limitati alle attività che saranno stabilite per la JEA

La funzionalità di Just Enough Administration (JEA) è disponibile di default in:

  • Windows Server 2016
  • Windows 10, version 1511 or later

Ma funziona anche se avete installato Windows Management Framework 5.0 in:

  • Windows Server 2012 R2
  • Windows Server 2012
  • Windows Server 2008 R2
  • Windows 8.1
  • Windows 8
  • Windows 7

In realtà Windows Server 2008 R2 ed Windows 7 non supportano i virtual accounts JEA e tutte le attività vengono eseguite dall’utente che si connette al JEA Endpoint.

Configurare JEA non è semplicissimo, perché bisogna sapere esattamente quali sono le attività che verranno svolte e quali sono i comandi che dovranno essere eseguiti. In ogni caso se avete attività da svolgere spesso o script da eseguire, JEA è un ottimo modo per ridurre la superficie di attacco ed implementare RBAC (Role Based Access Control). Un altro limite evidente è sicuramente quello che JEA funziona SOLO con PowerShell.

Per mostrarvi come funziona JEA, darò la possibilità ad un semplice utente di dominio di effettuare alcune operazioni sul server DNS (nel mio caso il domain controller DC1). Ho creato un utente di dominio e l’ho aggiunto ad un gruppo chiamato DNSOps.Il gruppo DNSOps è anch’esso un gruppo che non ha privilegi amministrativi.

Figura 1: Creazione dell’utente limitato ed aggiunta al gruppo DNSOps

Creazione del Role-Capability file

Il Role-Capability file permette di specificare cosa potrà essere fatto nelle sessioni remote di PowerShell. È possibile creare un nuovo file, che avrà estensione .psrc, e aggiungere le cmdlet, le funzioni e tutti i comandi necessari. Per avere una lista completa dei parametri utilizzabili e delle diverse parti del file .psrc vi rimando alla lettura dell’articolo https://docs.microsoft.com/en-us/powershell/jea/role-capabilities e dell’articolo https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/new-psrolecapabilityfile?view=powershell-5.1

Per creare un nuovo Role-Capability File è sufficiente eseguire sul domain controller o sul server DNS (nel mio caso si chiama DC1) PowerShell ISE, con privilegi elevati, e lanciare le seguenti cmdlet di PowerShell:

Cd ‘c:\Program Files\WindowsPowerShell\Modules’
Mkdir DNSOps
Cd DNSOps
New-ModuleManifest .\DNSOps.psd1
Mkdir RoleCapabilities
Cd RoleCapabilities
New-PSRoleCapabilityFile -Path .\DNSOps.psrc
Ise DNSOps.psrc

In questo modo verrà creato un nuovo file chiamato DNSOps.psrc che utilizzeremo per poter gestire il DNS.

Figura 2: Creazione di un Role-capability file DNSOps.psrc

Configurazione del Role-Capability file

Dopo aver creato il Role-Capability file DNSOps.psrc, è necessario configurarlo per i nostri scopi. Se avete eseguito la cmdlet Ise DNSOps.psrc nel passaggio precedente potrete già modificare il file. Come prima operazione consentiamo di riavviare solo il servizio DNS. Posizionatevi quindi sotto la riga che inizia per # VisibleCmdlets = e digitate:

VisibleCmdlets = @{ Name 'Restart-Service'; Parameters = @{ Name='Name'; ValidateSet = 'DNS'}}

Per consentire l’utilizzo di solo alcune cmdlet riferite alla gestione del DNS posizionatevi sotto la riga che inizia per # VisibleFunctions = e digitate:

VisibleFunctions = 'Add-DNSServerResourceRecord', 'Clear-DNSServerCache', 'GetDNSServerCache', 'Get-DNSServerResourceRecord' , 'Remove-DNSServerResourceRecord'

Per consentire l’utilizzo di solo alcuni eseguibili (nel mio caso whoami.exe) posizionatevi sotto la riga che inizia per # VisibleExternalCommands = e digitate:

VisibleExternalCommands = 'C:\Windows\System32\whoami.exe'

Salvate il file DNSOps.psrc. Il risultato è quello mostrato nella figura sotto:

Figura 3: Modifica del Role-capabilty file DNSOps.psrc

Creazione del Session-configuration file

Il Session-configuration file serve a definire cosa può essere fatto in una sessione JEA. Se una cmdlet, un parametro, il valore di un determinato parametro, un alias, uno script esterno o un eseguibile non sono presenti nel session-configuration file, allora non potranno essere utilizzati in una sessione JEA configurata per utilizzare quel session-configuration file.

Per creare un nuovo file, che avrà l’estensione .pssc, è sufficiente utilizzare la cmdlet New-PSSessionConfigurationFile. Per avere una lista completa dei parametri utilizzabili e delle diverse parti del file .pssc vi rimando alla lettura dell’articolo https://docs.microsoft.com/en-us/powershell/jea/session-configurations e dell’articolo https://docs.microsoft.com/it-it/powershell/module/Microsoft.PowerShell.Core/New-PSSessionConfigurationFile?view=powershell-5.1

Creiamo un nuovo file eseguendo sul nostro server DNS (nel mio caso si chiama DC1) da PowerShell ISE con privilegi elevati le seguenti cmdlet:

Cd ‘c:\Program Files\WindowsPowerShell\Modules\DNSOps’
New-PSSessionConfigurationFile -Path .\DNSOps.pssc -Full
Ise DNSOps.pssc

Dopo aver creato il file è possibile modificarlo. Da PowerShell ISE, nella scheda DNSOps.pssc, modificate il valore SessionType ‘Default in

SessionType = 'RestrictedRemoteServer'

Navigate fino alla linea #RunAsVirtualAccount = $true e rimuovete il comment # in modo tale che ci sia solo

RunAsVirtualAccount = $true

Spostatevi quindi alla linea che comincia con #RoleDefinitions e subito sotto scrivete il nome del gruppo di AD che volete usare per la gestione (nel mio caso DEMO\DNSOps):

RoleDefinitions = @{ 'DEMO\DNSOps' = @{ RoleCapabilities 'DNSOps' };}

Salvate il file DNSOps.pssc. Il risultato è quello mostrato nella figura sotto:

Figura 4: Modifica del session-configuration file DNSOps.pssc

Creazione del JEA Endpoint

Un JEA Endpoint è un endpoint PowerShell che è configurato in modo tale che solo alcuni utenti possano connettersi e abbiano accesso alle cmdlet, ai parametri e ai valori definiti dal session-configuration file. Un server può avere diversi JEA Endpoint ed ognuno di loro può essere utilizzato per diversi scopi amministrativi. Una volta che un utente si collega al JEA Endpoint avrà i privilegi assegnati al virtual account che è stato definito nel session-configuration file. Per approfondimenti sui JEA Endpoint vi rimando all’articolo https://docs.microsoft.com/en-us/powershell/jea/register-jea

Per creare un JEA Endpoint è possibile utilizzare la cmdlet Register-PSSessionConfiguration. Sul vostro server DNS da PowerShell ISE lanciate le seguenti cmdlet:

Register-PSSessionConfiguration -Name DNSOps -Path .\DNSOps.pssc
Restart-Service WinRM
Get-PSSessionConfiguration

Il risultato è quello mostrato in figura:

Figura 5: Creazione del JEA Endpoint

Verificate che DNSOps sia elencato tra gli Endpoint disponibili.

Se avete sbagliato a configurare un Endpoint potete sempre eliminarlo utilizzando la cmdlet Unregister-PSSessionConfiguration

Creazione di una sessione amministrativa

Per verificare che tutto funzioni correttamente utilizzerò una macchina remota per effettuare l’amministrazione. Da una macchina del dominio che voglio usare come postazione di amministrazione, dopo essermi loggato come Domain Admin (demo\administrator), mi collego con una sessione PowerShell remota a DC1 e verifico quali sono i permessi che ho a disposizione usando le seguenti cmdlet:

Enter-PSSession -ComputerName DC1
(Get-Command).count
Whoami.exe

Come si può notare dalla figura sotto, ho la possibilità come domain admin di usare 2006 cmdlet diverse:

Figura 6: Sessione remota PowerShell con privilegi da domain admin

Creazione di una sessione di Just Enough Administration (JEA)

Dalla stessa macchina di dominio che voglio utilizzare come postazione di amministrazione mi loggo questa volta come domain user (demo\nicferr) che fa parte del gruppo DEMO\DNSOps (che ho autorizzato nel Session-configuration file) e mi collego con una sessione PowerShell remota a DC1. Se lanciassi la cmdlet Enter-PSSession -ComputerName DC1 riceverei un messaggio di errore perché essendo un domain user non ho privilegi amministrativi su DC1. Ma se lancio Enter-PSSession -ComputerName DC1 -ConfigurationName DNSOps (dichiarando quindi di voler utilizzare una configurazione JEA) riesco a connettermi. Verifico quali sono i permessi che ho a disposizione usando le seguenti cmdlet:

Enter-PSSession -ComputerName DC1 -ConfigurationName DNSOps
(Get-Command).count
Whoami.exe

Figura 7: Connessione alla macchina DC! utilizzando la configurazione JEA

Come si può vedere dalla figura 7, il comando Whoami.exe non restituisce il logon name dell’utente (demo\nicferr) bensì quello del virtual account utilizzato da JEA (winrm virtual users\winrm va_1_demo_nicferr).

Provo quindi ad eseguire alcuni comandi per la gestione del DNS (ovviamente saranno concesse solo le cmdlet che ho definito nel role-capability file):

Get-DNSServerResourceRecord -zonename demo.lab
Add-DNSServerResourceRecord -zonename ‘demo.lab’ -A -Name ‘SVR1’ -IPv4Address ‘10.0.0.101’
Add-DNSServerResourceRecord -zonename ‘demo.lab’ -A -Name ‘SVR2’ -IPv4Address ‘10.0.0.102’
Remove-DNSServerResourceRecord -zonename ‘demo.lab’ -RRTYPE ‘A’ -Name ‘SVR2’ -Confirm

I risultati sono mostrati in figura:

Figura 8: Esecuzione dei comandi abilitati nel role-capability file

Provo anche a riavviare il servizio DNS utilizzando la cmdlet Restart-Service DNS ed in effetti il servizio viene riavviato. Se invece provo a riavviare un altro servizio non consentito nel role-capability file (ad esempio utilizzando la cmdlet Restart-Service WinRM) ricevo un messaggio di errore, come mostrato in figura:

Figura 9: Errore dovuto all’esecuzione di un comando non contenuto nel role-capability file

Distribuzione della configurazione JEA ad un altro computer

Una volta che avete validato la vostra configurazione JEA, sarà possibile distribuirla su tutti i computer che volete amministrare. Per poter riutilizzare la configurazione JEA che avete creato su vostro server DNS (nel mio caso DC1), potete copiare tutto il contenuto della cartella C:\Program Files\WindowsPowerShell\Modules\DNSOps del vostro server e incollarla nel nuovo server da gestire nello percorso C:\Program Files\WindowsPowerShell\Modules. Successivamente potete creare il nuovo JEA Endpoint utilizzando i comandi PowerShell:

Cd ‘c:\Program Files\WindowsPowerShell\Modules\DNSOps\RoleCapabilities’
Register-PSSessionConfiguration -Name DNSOps -Path .\DNSOps.pssc
Restart-Service WinRM

Figura 10: Copia della configurazione JEA sul nuovo server da gestire

Verificate con la cmdlet Get-PSSessionConfiguration che DNSOps sia disponibile come Endpoint.

Figura 11: Creazione del JEA Endpoint sul nuovo server da gestire

Conclusioni

La Just Enough Administration (JEA) consente di migliorare le condizioni di sicurezza, riducendo di fatto il numero di amministratori nei computer. Ciò avviene tramite la creazione per gli utenti di un Endpoint per eseguire attività amministrative in maniera limitata, per prevenire usi impropri. Poiché JEA consente di eseguire i comandi di amministratore senza avere accesso come amministratore, è possibile rimuovere gli utenti dai gruppi di sicurezza con privilegi elevati e renderli quindi utenti standard, adottando il principio di privilegio minimo.

Implementare Local Administrator Password Solution

Facebooktwittergoogle_plusredditlinkedin

Local Administrator Password Solution (LAPS) è un software Microsoft che permette di gestire le password degli amministratori locali in Windows. Quando installate il sistema operativo vi viene chiesto di inserire la password per l’utente amministratore locale del computer e spesso utilizzate questo account e la password impostata per potervi loggare localmente alla macchina se non riuscite a loggarvi al dominio. Gestire manualmente queste password, ammesso e non concesso che non sia un’unica password per tutti i vostri computer, è un’impresa non da poco quando si devono gestire centinaia se non migliaia di macchine. Immaginate cosa potrebbe succedere se la password venisse rivelata a persone indesiderate.

Local Administrator Password Solution (LAPS) permette di creare un repository centralizzato dove conservare le password per gli amministratori locali delle macchine (utenti che hanno il SID che finisce con .500) che sono collegate al dominio e vi permette di:

  • Avere una password univoca e quindi diversa su ogni computer che LAPS gestisce
  • Cambiare regolarmente la password dell’amministratore locale
  • Conservare le password in un attributo del computer in Active Directory
  • Configurare e controllare gli accessi alle password
  • Trasmettere in maniera sicura le password ai computer gestiti

LAPS funziona sia sulle versioni a 32 bit che a 64 bit di Windows 10, Windows 8, Windows 8.1, Windows 7, Windows Vista, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 e richiede che il livello funzionale del dominio sia almeno Windows Server 2003 o successivo.

Prima di utilizzare il tool sarà necessario aggiornare lo schema di Active Directory con la cmdlet Update-AdmPwdADSchema (inclusa nel modulo PowerShell che verrà installato insieme al tool) e distribuire il client MSI (magari utilizzando le Group Policy client-side extension).

Il tool è scaricabile dall’indirizzo https://www.microsoft.com/en-us/download/details.aspx?id=46899

Come funziona LAPS

Dopo aver distribuito il client sulle macchine da amministrare, ogni volta che avviene il refresh delle Group Policy, vengono effettuate le seguenti operazioni:

  • LAPS controlla se la password dell’amministratore è scaduta
  • Se la password è scaduta allora viene generata dinamicamente una nuova password, che viene conservata in un particolare attributo di AD del computer, e viene trasmessa al computer e quindi assegnata all’account amministrativo

Installazione di LAPS

Prima di poter configurare i computer, sarà necessario spostarli in una OU dedicata, a cui verranno successivamente associate le Group Policy per la gestione.

Scaricate LAPS e installate solo i tool di gestione. Nel mio caso l’ho installato sul domain controller. Disabilitate l’AdmPwd GPO Extension ed abilitate tutti management Tools, come mostrato in figura:

Figura 1: Schermata iniziale del tool Local Administrator Password Solution

Figura 2: Configurazione dei parametri del tool

Figura 3: Completamento dell’installazione

Terminata l’installazione del tool, lanciate un prompt di PowerShell con privilegi elevati ed eseguite i seguenti comandi:

Import-Module admpwd.ps

Update-AdmPwdADSchema

Set-AdmPwdComputerSelfPermission -Identity “Roma_Computers” (Roma_Computers è l’organizational unit dentro la quale ci sono i computer da gestire)

Ricordatevi che per poter aggiornare lo schema dovete eseguire la cmdlet Update-AdmPwdADSchema con privilegi di Enterprise Admin o di Schema Admin.

Figura 4: Configurazione e aggiornamento dello Schema

A questo punto create una nuova GPO e collegatela alla OU che volete gestire. Io ho chiamato la GPO con il nome LAPS e l’ho collegata alla OU chiamata Roma_Computers. Editate la GPO e dopo esservi spostati nel ramo Computer ConfigurationàPoliciesàAdministrative TemplatesàLAPS, modificate il parametro Enable local admin password management mettendolo su Enabled e il parametro Password Settings scegliendo lunghezza e durata della password, come mostrato in figura:

Figura 5: Configurazione dei parametri della Group Policy per il LAPS

Distribuzione del client LAPS

Per distribuire il client potete utilizzare i metodi che preferite, sia con l’installazione manuale che con la distribuzione tramite Group Policy client-side extension o con altri metodi ESD (Electronic Software Distribution).

Procedete quindi all’installazione del software e, nel caso l’abbiate fatta manualmente, ricordatevi di aggiornare le policy con il comando gpupdate /force.

Figura 6: Distribuzione del client LAPS tramite GPO

Figura 7: Applicazione della GPO sui pc client

Dopo aver riavviato il client per permettere l’installazione dell’agent di LAPS, potete tornare sul vostro server di amministrazione (nel mio caso il domain controller) e da Start aprite LAPS UI.

Digitate il nome del computer da ricercare e fate clic su Search. Vi apparirà la password dell’amministratore locale e la scadenza, come mostrato in figura:

Figura 8: Verifica della password tramite LAPS UI

In alternativa all’interfaccia grafica è anche possibile utilizzare la cmdlet Get-AdmPwdPassword CL1 Out-Gridview

Figura 9: Utilizzo di PowerShell per la visualizzazione della password

Oppure è possibile visualizzare il valore dell’attributo ms-Mcs-AdmPwd del Computer Account in modalità visualizzazione avanzata della console di Active Directory Users and Computers.

Figura 10: Attibuto ms-Mcs-AdmPwd del computer account in AD

Per permettere ai computer di poter aggiornare la password dell’amministratore locale quando scade è sufficiente eseguire con privilegi elevati la cmdlet di Powershell Set-AdmPwdComputerSelfPermission -Identity “Roma_Computers

Figura 11: Abilitazione per l’autoaggiornamento della password

Per impostazione predefinita i gruppi Domain Admins ed Enterprise Admins possono visualizzare le password gestite tramite LAPS. Se volete delegare ad un gruppo specifico la possibilità di vedere le password dell’amministratore locale allora sarà necessario eseguire con privilegi elevati la cmdlet di Powershell Set-AdmPwdReadPasswordPermission -Identity “Roma_Computers” -AllowedPrincipals “Roma_ITOps”

Figura 12: Delega amministrativa per LAPS

Conclusioni

Local Administrator Password Solution (LAPS) permette di semplificare enormemente la gestione delle password degli amministratori locali e soprattutto aumenta il livello di sicurezza delle postazioni di lavoro. Molto spesso l’utilizzo della stessa password, che si ripete da diversi anni, è una vulnerabilità sensibile delle nostre macchine e le espone alla possibilità di essere facilmente attaccate o di essere amministrate da utenti non autorizzati.

Maggiori informazioni le trovate al link https://technet.microsoft.com/it-it/mt227395.aspx

Novità introdotte in Client Hyper-V in Windows 10 Fall Creators Update

Facebooktwittergoogle_plusredditlinkedin

Moltissime sono le novità introdotte in Windows 10 Fall Creators Update che abbiamo avuto già modo di elencare nell’articolo Windows 10 Fall Creators Update, ci siamo!. Oggi mi voglio soffermare sulle novità relative ad Hyper-V. Nonostante Hyper-V sia stato introdotto nelle versioni Pro ed Enterprise fin dalla versione Windows 8 a 64 bit (il nome ufficiale è Client Hyper-V), sembra che sia ancora sconosciuto a diversi utenti e voglio approfittare di questo articolo per un piccolo refresh.

Per tutti coloro che si cimentano per la prima volta con Client Hyper-V consiglio di leggere l’articolo Introduzione a Hyper-V in Windows 10; in questo articolo mostrerò solo quelle che sono le novità introdotte nella versione Fall Creators Update di Windows 10 (versione 1709).

Installazione di Client Hyper-V

L’installazione di Client Hyper-V viene effettuata semplicemente cercando in Start la parola Hyper-V ed aprendo la console relativa all’installazione delle funzionalità aggiuntive di Windows. Dopo aver scelto la voce Hyper-V procedete cliccando su OK e riavviate il PC. Dopo un paio di riavvii l’hypervisor sarà stato installato e potrete procedere alla gestione utilizzando l’Hyper-V Manager.

Figura 1: Installazione della funzionalità aggiuntiva di Hyper-V in Windows 10

Figura 2:Installazione completata e riavvio del client Windows 10

La console di Management di Client Hyper-V è una classica MMC 3.0 in tutto e per tutto uguale a quella presente su Windows Server. Infatti la console può essere utilizzata per gestire Server Hyper-V remoti.

Figura 3: Hyper-V Manager – Console di gestione di Hyper-V

Default Switch

Come potrete vedere visitando le configurazioni relative al Virtual Switch Manager, in questa versione di Windows 10 è stato creato automaticamente uno switch chiamato Default Switch che permette alle macchine virtuali di condividere la connessione dell’host attraverso una NAT (Network Address Translation). Non importa quindi se siete collegati con un cavo o se siete in Wi-Fi: avrete subito la possibilità di far ricevere alle vostre macchine le configurazioni di rete (DHCP e DNS) e di farle navigare. Fantastico!

Il default switch una volta creato non può essere rinominato o rimosso. Infatti tutte le impostazioni sono in grigio (non modificabili), come mostrato in figura:

Figura 4: proprietà del Default Switch

Ovviamente nessuno vi vieta di creare nuovi switch (Interni, Privati oppure Esterni) e di configurarli come meglio credete, collegandoli alla rete cablata oppure alla rete Wi-Fi.

Figura 5: External Switch collegato alla rete cablata

Quick Create virtual machine gallery

Già nella Build Insider 15002 rilasciata a Gennaio 2016 e poi in via definitiva nella versione Windows 10 Creators Update era stata introdotta In Client Hyper-V la possibilità di creare velocemente macchine virtuali utilizzando il pulsante Quick Create. Se volete approfondire vi rimando all’articolo Creare una macchina virtuale con Hyper-V e all’articolo Hyper-V virtual machine gallery and networking improvements.

Figura 6: Quick Create VM presente nella versione Windows 10 Creators Update (1703)

Nella versione Windows 10 Fall Creators Update (1709) il wizard è stato migliorato e vi permette di creare macchina virtuali partendo da una galleria di immagini già pronte (un’immagine chiamata Windows 10 dev environment è già disponibile di default). Cliccando sul pulsante Quick Create si aprirà una finestra da cui potrete scegliere quale immagine installare. Io ho scelto quella di default ed è iniziato un download da 12,73 GB, come mostrato in figura:

Figura 7: Creazione di una nuova macchina virtuale partendo da un’immagine presente nella Gallery

Figura 8: Download dell’immagine dalla gallery Microsoft

Al termine del download avviate la macchina virtuale e procedete alle successive configurazioni.

Figura 9:Installazione della VM completata

Ovviamente potete creare anche macchine virtuali utilizzando una vostra ISO oppure utilizzando un file vhd o vhdx esistente scegliendo Local Installation Source, come mostrato in figura:

Figura 10: Installazione partendo da una ISO o da un virtual disk esistente

Figura 11: Creazione della VM completata, con la possibilità di modificarne i parametri prima dell’avvio

Se volete aggiungere la vostra immagine personalizzata alla galleria di Windows 10, per poterla poi successivamente riutilizzare, potete seguire i passaggi descritti nell’articolo Create your custom Quick Create VM gallery

Virtual Machine sharing

Un’altra novità interessante introdotta in Client Hyper-V è la possibilità di esportare la macchina virtuale (anche da accesa) in modo tale da poterla condividere con altri PC. La funzione di Share permette di creare un file .vmcz all’interno del quale ci sono i file di configurazione e i dischi della macchina virtuale, che vengono anche compressi. Dopo aver spostato il file su un altro host con almeno Windows 10 Fall Creators Update e Client Hyper-V installato, semplicemente cliccando due volte sul file, la macchina viene direttamente importata e sarà utilizzabile. Più semplice di così???

Nota: questa funzione non permette di esportare nessun Checkpoint. Se volete esportare eventuali checkpoint che avete creato, dovrete utilizzare la funzione Export dall’Hyper-V Manager, cliccando col tasto destro sulla VM da esportare.

Figura 12: Esportazione e compressione della VM in formato .VMCZ tramite la funzionalità di Sharing

Figura 13: importazione della VM direttamente dal file .VMCZ

Nota: Se doveste ricevere un messaggio di errore che dice che non siete autorizzati ad importare la macchina, assicuratevi che l’utente con cui siete loggati sia parte del gruppo Hyper-V Administrators

Automatic Checkpoint

Dalla versione di Windows 10 Fall Creators Update, Client Hyper-V crea automaticamente un Checkpoint quando la macchina virtuale viene avviata (solo se non ci sono altri Checkpoint esistenti). Questa funzionalità è abilitata di default ma può essere facilmente modificata dalle proprietà della VM oppure eseguendo il comando PowerShell Set-VM –Name NomeDellaVM –AutomaticCheckpointsEnabled . Quando la VM viene spenta il Checkpoint viene rimosso e viene effettuato il Merge dei dischi.

Figura 14: Automatic Checkpoint creato all’avvio della VM

Figura 15: funzionalità di Automatic Checkpoint abilitata di default

Pass-Through della batteria

In Windows 10 Fall Creators Update la macchina virtuale è capace di vedere lo stato di carica della batteria. Questo vi permette di poter fare dei test all’interno del sistema operativo utilizzando le funzioni di risparmio energetico o le ottimizzazioni che Windows usa quando lo stato di carica della batteria è troppo basso. Oppure banalmente se state utilizzando la macchina virtuale in modalità Schermo intero potreste accorgervi che non avete più batteria J

Figura 16: Lo stato di carica della batteria è visualizzato anche all’interno della VM

Conclusioni

Davvero interessanti le novità introdotte in Client Hyper-V. Trovo davvero utili alcune delle funzionalità che vi ho elencato e la mia preferita è quella degli Automatic Checkpoint. E la vostra qual è?