Archivi categoria: powershell

PowerShell Core 6: ancora Open Source in trionfo

Facebooktwittergoogle_plusredditlinkedin

E’ passato più di un anno e mezzo da quando il progetto PowerShell 6 è arrivato su GitHub (https://github.com/powershell/powershell). Per la prima volta PowerShell non è solo OpenSource, ma addirittura Cross-Platform. La nuova shell, con l’obiettivo principale di creare un ambiente leggero mantenendo una buona compatibilità con le versioni precedenti, è ormai stata rilasciata in versione stabile su una moltitudine di sistemi operativi. E’ infatti possibile installare la nuova release su tutti i sistemi operativi Windows client a partire da Windows 7 e su Windows Server a partire da 2008 R2, oltre che su molteplici distribuzioni Linux (CentOS, RedHat. Debian, Fedora, OpenSuse) ed addirittura MacOS dalla versione 10.12.

L’installazione è molto semplice e va effettuata a partire dal Setup scaricato direttamente dalla pagina download del progetto (https://github.com/PowerShell/PowerShell/releases), selezionando la versione relativa al proprio sistema operativo. Il setup della versione per Windows x64 ha una dimensione di circa 50MB.

Dopo aver accettato le condizioni e confermato il path per l’installazione possiamo aprire PowerShell 6 mettendo un segno di spunta su “Launch PowerShell”

Per avviare PowerShell successivamente è possibile richiamare pwsh.exe dal prompt dei comandi se siamo su Windows, o avviare pwsh se siamo su Linux o MacOS.

Come possiamo notare stiamo utilizzando l’edizione Core di PowerShell 6, che come abbiamo anticipato è molto leggera ed ha caratteristiche di compatibilità elevate, ma non è possibile utilizzare gli stessi CmdLet dell’edizione Desktop. E’ importante notare che le due edizioni possono coesistere su uno stesso sistema. Se proviamo ad eseguire sulla stessa macchina il comando powershell vediamo che è possibile utilizzare la PowerShell completa.

Potrebbe capitare di leggere della documentazione su questi due componenti, e li vediamo spesso indicati come FullCLR (Windows PowerShell) e CoreCLR (PowerShell Core)

Aiutiamoci con Windows Subsystem for Linux e scopriamo quanti moduli sono disponibili nelle due edizioni di PowerShell. Proviamo a lanciare su entrambe il comando Get-Module -ListAvailable , che ci restituisce l’elenco dei moduli utilizzabili, redirezionando l’output al comando Linux wc -l, che ci indica il numero di righe di cui questo elenco è composto. Il comando completo è quindi:

Get-Module -ListAvailable bash -c “wc -l”

Proviamo ad eseguirlo su PowerShell Core

E successivamente su PowerShell

La differenza è notevole, 22 moduli contro 100, ma come al solito parliamo di progetti nati da pochissimo tempo e sui quali viene investito un gran numero di risorse, quindi ci aspettiamo delle grosse novità in tempi brevi.

Ricordiamo ovviamente che sui sistemi operativi non Windows è utilizzabile unicamente l’edizione Core, ed a questo proposito indichiamo che su alcune distribuzioni Linux si rilevano problemi nell’ottenimento dell’ultima release utilizzando l’opzione update dei vari package manager. Se vi trovate in questa situazione è sufficiente disinstallare e reinstallare il componente utilizzando:

Sulle distribuzioni Debian/Ubuntu:

sudo apt remove powershell && sudo apt-get install powershell

Sulle distribuzioni RedHat/CentOS:

sudo yum remove powershell && sudo yum install powershell

Sul futuro di PowerShell Core, quindi, sappiamo che la direzione su cui il team di sviluppo si sta muovendo è quella di aumentare il numero dei comandi supportati in modo da avere sistemi, anche eterogenei, sempre più in simbiosi ed in grado di scambiarsi il maggior numero di informazioni possibili, così da permettere un management sempre più centralizzato.

Nel frattempo Windows PowerShell continua ad essere supportato ma probabilmente non ci saranno grossi sviluppi futuri.

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 […]

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.

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

Facebooktwittergoogle_plusredditlinkedin

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

How to: installare Azure Powershell

Facebooktwittergoogle_plusredditlinkedin

Chi come me segue il mondo Microsoft da tanti anni sa sicuramente che dietro a tutti i sistemi operativi e prodotti c’è Powershell.

Automatismo, velocità e potenza sono solo alcuni dei vantaggi di conoscere Powershell per ottimizzare al meglio la gestione della nostra infrastruttura, “on premise” e in “Cloud” (Microsoft Azure). In questa mini guida vediamo come installare il modulo per gestire le nostre risorse in Azure.

Step 1

Primo passo è quello di verificare se abbiamo, sulla nostra macchina, installato il modulo PowerShellGet necessario per installare gli elementi dalla Powershell Gallery.

Eseguire il seguente comando:

Get-Module PowerShellGet -list | Select-Object Name,Version,Path

 L’ouput sarà simile alla seguente schermata:

PS C:\WINDOWS\system32> Get-Module PowerShellGet -list | Select-Object Name,Version,Path

Name                Version Path
—-                    ——-    —-
PowerShellGet   1.0.0.1  C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PowerShellGet.psd1

Se così non fosse seguire questo articolo (Come ottenere PowerShellGet) per installarlo.

Step 2

Secondo passo è quello di installare Azure Powershell così da poter amministrare e gestire le risorse che abbiamo in Azure.

Eseguire il seguente comando (con privilegi elevati):

# Install the Azure Resource Manager modules from the PowerShell Gallery
Install-Module AzureRM

La prima volta che eseguite il comando vi verranno presentati i seguenti messaggi, rispondete “S” al primo e “S” o “T” al secondo per proseguire:

PS C:\WINDOWS\system32> Install-Module AzureRM

Per continuare è necessario il provider NuGet
PowerShellGet richiede il provider NuGet versione ‘2.8.5.201’ o successiva per interagire con i repository basati su
NuGet. Il provider NuGet deve essere disponibile in ‘C:\Program Files\PackageManagement\ProviderAssemblies’ o
‘C:\Users\m.serra\AppData\Local\PackageManagement\ProviderAssemblies’. Puoi anche installare il provider NuGet
eseguendo ‘Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force’. Vuoi che PowerShellGet installi e
importi ora il provider NuGet?
[S] Sì  [N] No  [O] Sospendi  [?] Guida (il valore predefinito è “S”): S

Archivio non attendibile
Stai installando i moduli da un archivio non attendibile. Se ritieni attendibile questo archivio, modifica il relativo
valore InstallationPolicy eseguendo il cmdlet Set-PSRepository. Vuoi installare i moduli da ‘PSGallery’?
[S] Sì  [T] Sì a tutti  [N] No  [U] No a tutti  [O] Sospendi  [?] Guida (il valore predefinito è “N”): Si

Attendere l’installazione dei vari pacchetti.

image

Se si dispone di una versione precedente alla versione 2.8.5.201 di NuGet, viene richiesto di scaricare e installare la versione più recente di NuGet.

Il modulo AzureRM è un modulo di rollup per i cmdlet di Azure Resource Manager, qualsiasi modulo di Azure PowerShell non installato precedentemente viene scaricato da PowerShell Gallery.

Se è installata una versione precedente di Azure PowerShell verrà visualizzato un errore, per risolverlo seguire questo articolo: Eseguire l’aggiornamento a una nuova versione di Azure PowerShell.

Step 3

Dopo aver installato il modulo, è necessario importarlo in una sessione di PowerShell per avere disponibili tutti i cmdlet.

Eseguire il seguente comando (con o senza privilegi elevati):

Import-Module AzureRM

Nota: se vi esce il seguente errore verificare se l’esecuzione degli script e abilitata con il comando Get-ExecutionPolicy

PS C:\WINDOWS\system32> Import-Module AzureRM
Import-Module : Impossibile caricare il file C:\Program Files\WindowsPowerShell\Modules\AzureRM\4.0.2\AzureRM.psm1.
L’esecuzione di script è disattivata nel sistema in uso. Per ulteriori informazioni, vedere about_Execution_Policies
all’indirizzo
http://go.microsoft.com/fwlink/?LinkID=135170.
In riga:1 car:1
+ Import-Module AzureRM
+ ~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : Errore di protezione: (:) [Import-Module], PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess,Microsoft.PowerShell.Commands.ImportModuleCommand

Se è in Restricted mode eseguire il seguente comando per sbloccare l’esecuzione degli script  erispondere “S” alla domanda.

Set-ExecutionPolicy Unrestricted

Modifica ai criteri di esecuzione
I criteri di esecuzione facilitano la protezione dagli script non attendibili. La modifica dei criteri di esecuzione
potrebbe esporre l’utente ai rischi di sicurezza descritti nell’argomento della Guida about_Execution_Policies
all’indirizzo http://go.microsoft.com/fwlink/?LinkID=135170. Modificare i criteri di esecuzione?
[S] Sì  [T] Sì a tutti  [N] No  [U] No a tutti  [O] Sospendi  [?] Guida (il valore predefinito è “N”):

Step 4 – Aggiornare Azure Powershell

Se si volesse aggiornare ad una versione più recente Azure Powershell esegiure il seguente comando:

# Install the Azure Resource Manager modules from the PowerShell Gallery
Install-Module AzureRM –AllowClobber

Altri comandi e link utili:

Controllo della versione di Azure Powershell

Get-Module AzureRM -list | Select-Object Name,Version,Path

Come ottenere PowerShellGet

Versione sistema operativo: Il sistema operativo è Windows 10 o Windows Server 2016 –> Integrato in Windows Management Framework (WMF) 5.0 incluso nel sistema operativo
Versione sistema operativo: si vuole eseguire l’aggiornamento a PowerShell 5 –> Installare la versione più recente di WMF

Versione sistema operativo: è in esecuzione una versione di Windows con PowerShell 3 o 4 –> Ottenere i moduli PackageManagement

Altri metodi di installazione

Per informazioni sull’installazione con altri metodi (piattaforma Web o il pacchetto MSI): Other installation methods

Guida ad Azure Powershell

Per altre informazioni sull’uso di Azure PowerShell:  Guida introduttiva ad Azure PowerShell