Windows PowerShellAutomatizzare la gestione di Active Directory

Don Jones

Uno dei principali problemi della prima versione di Windows PowerShell è stato il tempo. Il team Windows PowerShell è stato messo sotto pressione per riuscire a completare il prodotto (contemporaneamente ha avuto luogo il lancio di Exchange Server 2007, dipendente da Windows PowerShell) e anche il team Active

Directory ha avuto molto da fare in quel periodo (tra le altre cose, era in lavorazione anche Windows Server® 2008). Ecco perché Windows PowerShell è stato rilasciato con un numero ridotto delle eccellenti capacità di gestione di Active Directory®.

Per essere chiari, Windows PowerShell® non è completamente privo di funzionalità Active Directory. Anzi, a dire il vero, il team Windows PowerShell ha fatto uno sforzo eroico per approntare un supporto decente per Active Directory Services Interface (ADSI), una tecnologia di scripting molto pratica, già nota agli utenti di VBSCRIPT.

Il metodo ADSI

Come funzionamento, ADSI è simile a Windows® Management Instrumentation (WMI). L'utente scrive una query utilizzando una sintassi speciale. La query viene trasmessa a un computer remoto (ad esempio, un controller di dominio) e poi eseguita. Il risultato della query è un oggetto o una raccolta di oggetti Active Directory (ad esempio, un utente o un gruppo), mentre viene generato un riferimento all'oggetto con cui è quindi possibile lavorare. È possibile modificare le proprietà dell'oggetto o eseguire dei metodi per salvare le modifiche, creare nuovi oggetti, cancellare oggetti, e così via. Ad esempio, per creare un utente, è possibile eseguire una query per richiedere l'unità organizzativa (OU) o il contenitore in cui inserire l'utente. L'oggetto restituito ha un metodo Create, che può essere utilizzato per creare l'utente.

A livello di base, l'uso di Windows PowerShell sembra semplice e chiaro. Ad esempio, questo comando può richiamare un utente e visualizzarne l'attributo Company:

$user = [ADSI]"LDAP://cn=Ringo,ou=Singers,dc=company,dc=pri"
$user.Get("Company")

È possibile eseguire il piping dell'utente a Get-Member per poterne vedere le proprietà e i metodi. Sfortunatamente, Windows PowerShell 1.0 non è particolarmente affidabile nell'implementazione di questi oggetti directory. Come mostrato nella figura 1, lo shell non enumera gli attributi directory dell'oggetto, né visualizza i metodi di quest'ultimo, ad esempio il metodo Get utilizzato in precedenza.

Figura 1** Il piping dell'utente a Get-Member per visualizzarne le proprietà **(Fare clic sull'immagine per ingrandirla)

Questo supporto è leggermente migliorato nella CTP (Community Technology Preview) di Windows PowerShell 2.0, ma soltanto in una certa misura. La conclusione è che il componente Microsoft® .NET Framework sottostante non permette agli amministratori di vedere agevolmente quello che gli serve. Dopo tutto, il framework è stato originariamente progettato per gli sviluppatori. L'altro problema è che il team Windows PowerShell ha competenze specifiche e limitate, mentre, per ottenere un buon supporto Active Directory, è necessario contare su persone esperte di directory. In altre parole, sul team Active Directory. Ma, ne sono sicuro, ciò avverrà presto. Dopo tutto, Windows PowerShell è ancora giovane. Il problema è: cosa fare nel frattempo?

Come ricorderete, ho già illustrato l'uso delle tecnologie ADSI incluse in Windows PowerShell nel numero di giugno 2007 di questa rubrica (technetmagazine.com/issues/2007/06/PowerShell). A chi desidera avere altri dettagli sulla tecnica "nativa", suggerisco di rileggere questa rubrica. In questo numero, invece, voglio illustrare alcuni altri approcci.

Un ecosistema molto ricco

L'architetto di Windows PowerShell Jeffrey Snover cita spesso il ricco ecosistema che circonda Windows PowerShell. Con questo vuole dire semplicemente che il team ha fatto un ottimo lavoro assicurandosi che tutti, non solo i programmatori Microsoft, possano estendere le funzionalità di Windows PowerShell. Alcune importanti aziende hanno già intrapreso questo percorso creando cmdlet Windows PowerShell nativi che permettono di amministrare i loro prodotti dalla riga di comando: VMWare, IBM, Citrix e Foundry sono tra queste.

Uno dei miei esempi preferiti di questo ricco ecosistema è il software di Quest. L'azienda offre una serie di cmdlet gratuiti e non commerciali, appositamente progettati per la gestione di Active Directory. Questi cmdlet possono essere scaricati dal sito quest.com/powershell. Tra i programmi offerti, anche PowerGUI (powergui.org), una GUI gratuita e non commerciale per Windows PowerShell rivolta alle persone non ancora pronte ad affrontare l'esperienza della riga di comando. Con PowerGUI, è più facile imparare a utilizzare i cmdlet di gestione di Active Directory. E, una volta utilizzati questi cmdlet, non sarà più possibile farne a meno. I cmdlet aggiungono alla gestione di Active Directory praticità e potenza senza precedenti. Per saperne di più su PowerGUI, basta leggere il numero di gennaio 2008 della rubrica Toolbox, disponibile all'indirizzo technetmagazine.com/issues/2008/01/Toolbox.)

Il metodo Windows PowerShell

Tutto ciò che implica l'impiego dei cmdlet può essere di fatto definito il metodo Windows PowerShell. Questo metodo significa non avere più a che fare con script tradizionali o strani oggetti di programmazione. In pratica, tutto viene risolto con un'unica riga. Un'unica riga di comando che importa un file di CSV e utilizza le informazioni in esso contenute per creare dozzine o persino centinaia di nuovi utenti Active Directory:

Import-CSV 'C:\provision1.csv' |
ForEach-Object {New-QADUser -organizationalUnit 'company.pri/Singers' -name ($_.'First Name' + '.' + $_.'Last Name') 
-samAccountName $_.'Logon name' -city $_.city -title $_.'Job title' -department $_.department} 

Certo, il comando è piuttosto lungo, ma è anche sorprendentemente potente. Inizia con Import-CSV, un cmdlet di shell nativo che legge un file CSV e restituisce degli oggetti. Ogni riga del file CSV è un singolo oggetto, mentre le colonne sono le proprietà dell'oggetto. Nel mio file Provision1.csv, i nomi delle colonne sono descrizioni quali "Logon Name" e "First Name", nomi che non hanno una mappatura diretta agli attributi utente di Active Directory. È una prassi comune per i file di questo tipo utilizzare nomi di colonna di tipo familiare al posto di quelli specifici di Active Directory. Dopotutto, un file del genere potrebbe provenire da una persona che lavora nell'ufficio del personale dell'azienda, una persona che molto probabilmente non sa che Last Name è effettivamente un attributo sn di Active Directory.

Una volta che tutti i dati del file di CSV sono stati importati e convertiti in oggetti, tali oggetti vengono inseriti nel cmdlet ForEach-Object, che esegue un blocco di codice - quello tra le parentesi graffe della riga di comando - per ogni oggetto. In pratica, per ogni riga del file CSV, questo script verrà eseguito una volta. Nello script, la variabile speciale $_ è un riferimento all'oggetto corrente, ovvero alla riga corrente del file CSV.

Questo è evidente per ogni oggetto, nell'esecuzione del cmdlet New-QADUser. Si tratta di uno dei quasi dodici cmdlet del componente aggiuntivo Quest. Il nome QADUser richiede un ulteriore commento. La Q, come è facile immaginare, sta per Quest. Questa convenzione di denominazione è stata pensata per evitare conflitti con il cmdlet New-ADUser che verrà prodotto in futuro dal team Microsoft Active Directory. In questo modo, entrambi i cmdlet verranno caricati nello shell contemporaneamente, ma resteranno sempre facilmente distinguibili, sia per lo shell che per gli utenti.

Il resto della riga di comando consiste di parametri per il cmdlet New-QADUser. Si inizia con la specifica di organizationalUnit, che è l'unità in cui vanno creati tutti i nuovi utenti. Segue l'attributo del nome, impostato come contenuto della colonna First Name, il punto e il contenuto della colonna Last Name.

Qui vale la pena notare una cosa interessante: Il parametro city modificherà di fatto l'attributo I (o Locality-Name) in Active Directory. Il cmdlet può accettare anche un parametro denominato l, che fa la stessa cosa. Nella maggior parte dei casi, i parametri che fanno riferimento agli attributi di Active Directory possono utilizzare sia il nome dell'attributo che l'etichetta di testo dello strumento Utenti e computer di Active Directory.

L'altro metodo Windows PowerShell

Active Directory è un archivio gerarchico, e uno dei punti di forza di Windows PowerShell è la sua capacità di esporre ogni archivio gerarchico come un'unità disco, consentendo l'uso di gruppi di comandi molto conosciuti come Dir, Del, Ren, Copy, e così, per gestire una varietà di archivi. Sfortunatamente, Windows PowerShell 1.0 non viene fornito con un provider PSDrive per Active Directory, il che significa che lo shell non ha modo di esporre Active Directory come un'unità.

Fortunatamente, quel ricco ecosistema di cui abbiamo discusso prima torna in gioco con le estensioni della PowerShell Community. Stiamo parlando di un componente aggiuntivo gratuito e open-source disponibile sul sito codeplex.come/powershellcx. Una volta installate, queste estensioni vi permetteranno di indirizzare facilmente lo shell al vostro nome dominio per iniziare a gestire la directory come se si trattasse di un'unità:

CD COMPANY:
CD SINGERS
DIR

Questi comandi verranno modificati nel dominio COMPANY, nell'OU Singers, quindi visualizzeranno un elenco di oggetti, come illustrato nella figura 2. A questo punto, è possibile iniziare a utilizzare comandi quali Del per cancellare un utente, Md di creare una nuova OU, e così via. Ci sono alcune cose da dire sul provider PSDrive delle estensioni della community. Sostanzialmente, si tratta di cose che hanno a che fare con la funzionalità che ci si aspetterebbe di implementare, ma che non è disponibile per via della mappatura inesatta con Active Directory. Queste cose richiedono un'estrema attenzione: modificando la radice del dominio ed eseguendo del * -recurse, di fatto si elimina ogni oggetto del dominio, sempre che si sia autorizzati a eseguire questo comando. Per impostazione predefinita, non viene neanche richiesta conferma dell'operazione. Certo, la riga di comando è potente, ma questa potenza comporta una buona dose di rischio per chi non è particolarmente esperto e attento.

Figura 2** Uso delle estensioni della PowerShell Community per indirizzare lo shell e gestire la directory **(Fare clic sull'immagine per ingrandirla)

Come utilizzare PowerShell oggi

Gli studenti dei miei corsi chiedono sempre cosa possono fare con Windows PowerShell oggi. Dopotutto, non tutti i prodotti Microsoft sono stati riprogettati per potersi avvalere di Windows PowerShell e si potrebbe pensare che Windows PowerShell stia ancora aspettando che l'ambiente intorno si adegui.

Ma questo adeguamento è già in atto. Anche se Microsoft ha non ancora preparato Active Directory all'uso della gestione dalla riga di comando, altri si sono già cimentati in questa impresa e hanno ottenuto dei risultati abbastanza buoni. Windows PowerShell può essere utilizzato per eseguire molte attività amministrative, compresa l'automazione di alcune delle attività più onerose in termini di tempo e carico di lavoro, come la creazione di gruppi di nuovi utenti. Il trucco sta nel riuscire a scoprire alcune delle cose che la community sta facendo per rendere Windows PowerShell più utile nell'immediato. (A questo scopo, può essere utile visitare PowerShellCommunity.org, un sito co-sponsorizzato da Microsoft e che si avvale del mio contributo per l'amministrazione). Dotando Windows PowerShell degli strumenti giusti, potete iniziare lo scripting di alcune delle attività amministrative più onerose dal punto di vista del tempo e diventare amministratori più efficienti ed efficaci.

Don Jones è co-autore di Windows PowerShell: TFM, seconda edizione, autore di VBSCRIPT, WMI e ADSI Unleashed e direttore di PowerShellCommunity.org.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.